Skip to main content

22.02.08 - Req. Gathering

User Stories

Have a list of actors - with 'representations' as personas Have use cases - functions they will do Now bring them together and add the why to it

As a role, I want goal/desire so that outcome

Highly common in Agile Teams. Single sentence - to represent a single requirement

  • a role (actor/stakeholder etc)
  • goal/function/action/use case
  • an effect/outcome/motivation - the WHY behind the WHAT
ProsCons
Concise and ClearDifficult to use in BIG projects
Little maintenanceLoose detail and formality
Creates clear requirements checklistDone describe process or tasks or context
Breaks down project into chunks and can rank for importance

Documenting Requirements

Requirement vs Specification

Requirement - What a stakeholder needs to be able to do Specification - What the software must do to meet the requirement above

Functional vs Non-Function

FunctionalNon-Function
Functions the user to achieve something (requirements)Constraints on what the user needs to do (requirements)
Functions the software will include (specification)Constraints on how well the system performs (specifications)

Functional requirement has should in it

Investigating/Validating Requirements

Investigation Techniques

All about the questions you ask Its rarely enough to accept the initial answer to a question because that should highlight more things to ask about

Use the initial questions you had from the brief

  • to set investigation goals, choose a technique to best learn about these things

Surveys

Good for contacting lots of people, getting a majority view Bad for actually understanding something in detail

Top Mistakes:

  • Sending a badly made questionnaire
    • Can be designed well to extract a good answer
  • Reinvent the wheel
    • Well tested proven surveys can use
    • Perceived Ease of Use Scale, usability questionnaires etc
  • 2 part questions, leading questions, surveys are too long

Interviews and Focus Groups

Gives you the freedom to ask follow up questions

  • Strong interviews have 2 characteristics
    • Open minded, unbiased, ready to listen
    • Gets interviewee to be relaxed and chatty and involved
  • Get people to do more than just talk
  • Must have a plan for the interview, otherwise it will fall through

Interviews vs Focus Group

ProsCons
More people at oncePossible Conflict
Faster coverage of usersCan get a 'dominant speaker'
Discuss differencesTakes longer to discuss per Q

Ideally 2 organisers so one can note take

Observations

Allows you to see the things people didn't say People are not good at realising everything that's important for you to know

Technology Tours

Helps you identify what things 'your new software' will work with The kind of setup and scenario it will be used with, e.g. on a whiteboard

Ethnography

No better way to learn than doing Targeting specific tasks, or roles in the company.

Overall Strategy

Most mistakes are because people don't have a strategy One method can help understand the results of another

If system shall do this, its a requirement

Summary

Requirement: What a stakeholder needs to be able to do Specification: What the software must do to meet the requirement above Functional: What it will make user achieve(Req)/Functions the software will include (Spec) Non-functional: What the user needs to do(Req)/How well the system performs (Spec)